Answer invalid_client when token endpoint client authentication fails - #363

The token endpoint answered access_denied to a confidential client which
presented no authentication, and to one whose client assertion did not
hold: no JWKS available, a signature which did not verify, or the wrong
Issuer, Subject or Audience. RFC 6749 section 5.2 names invalid_client
for the first and RFC 7521 section 4.2.1 requires it for the second. A
wrong secret already got it, and wip-version-7 answers it for all of
these.

The status stays HTTP 401, and League adds its WWW-Authenticate challenge
when the request used the Authorization header. The response no longer
carries the hint access_denied had, and a client which compares the error
member with the old value needs the new one. Since ErrorResponder logs
nothing on this branch, the rule logs the reason for each of these
refusals at warning level with the client_id.

The backstop in AuthCodeGrant answers the same. No request reaches it
today, and it runs before the code is decrypted, so it cannot tell an
invalid grant from missing authentication as wip-version-7's does.

The end-to-end test now has one constant for the answer, and adds the
challenge and private_key_jwt, whose checks in the rule had no test on
this branch. It passes unedited on wip-version-7.

Assisted-by: Claude Code (claude-opus-5-5, implementation & integration tests)
Assisted-by: Google Antigravity (gemini-3.8-flash-high, review)

The release adds the option refusing the implicit flow for confidential
clients. The token endpoint now answers invalid_client where it answered
access_denied, which a client comparing the error member has to follow,
and the reason has moved from the response to the log.

Assisted-by: Claude Code (claude-opus-5-5, upgrade note)

15fb6b4 logs why client authentication failed. One reason quotes the
message of the signature check, and the library's answer to an unknown
algorithm quotes the alg header of an assertion nobody has verified yet.
SimpleSAMLphp's file log handler writes messages as they are, so a caller
with no credentials who knows the client_id of a client with a usable
JWKS could write lines of their own into the log.

The reason is now cut at 1000 bytes, and every run of bytes outside
printable ASCII becomes one space. Stripping control characters alone
would leave U+0085 and U+2028, which some consumers break lines on.

wip-version-7 logs the same message as it is, in
AuthenticatedOAuth2ClientResolver. A merge of this keeps that branch's
rule, so the new test fails there until that line gets the same treatment.

Assisted-by: Claude Code (claude-opus-5-5, implementation & integration tests)
Assisted-by: Google Antigravity (gemini-3.8-flash-high, review)

A client assertion which did not parse left ClientAuthenticationRule as
an uncaught JwsException. Its message quotes raw claim values, and
SimpleSAMLphp's exception handling logs it as it is, so a caller with no
credentials who knows the client_id of a confidential client could write
lines of their own into the log, with no JWKS or valid signature involved.
The client also got the error page instead of a token error.

The rule now catches JwsException around the parse and refuses like any
other failed client authentication: invalid_client, with the reason cut
and reduced to printable ASCII in the log. This also covers an expired
assertion, a missing claim, and a Subject other than the Issuer.

The catch stops at JwsException, which the library wraps every failure of
the token in, so a parser which can not start stays an error of the OP.

The upgrade note also said the old answers carried a hint. They had no
such member: OidcServerException appends the hint to error_description,
and the note now says that.

wip-version-7 refuses these in AuthenticatedOAuth2ClientResolver. Merging
this keeps that branch's rule, so both log tests fail there until the
line named in af7c2aa gets the same treatment.

Assisted-by: Claude Code (claude-opus-5-5, implementation & integration tests)
Assisted-by: OpenAI Codex (gpt-6.1-sol, xhigh review)